What the issue is

isTypeofInTypePosition (specSchemaAccess.ts:208-215) checks two parent kinds:

if (Node.isTypeQuery(parent)) return true;
// typeof inside a type argument like z.infer<typeof X>
if (parent.getKind() === SyntaxKind.TypeOfExpression) return true;

In the TypeScript AST these are two distinct node kinds:

• TypeQuery (SyntaxKind.TypeQuery) is type-level typeof X — used in type T = typeof X, z.infer<typeof X>, let a: typeof X. This is what line 211 matches, and it already covers every z.infer<typeof X> case.
• TypeOfExpression (SyntaxKind.TypeOfExpression) is the value-level runtime unary operator — const k = typeof x, if (typeof x === 'object') — which evaluates to a string at runtime. This is what line 213 matches.

So the comment on line 212 ("typeof inside a type argument like z.infer") is factually incorrect about what TypeOfExpression matches — that case is TypeQuery, already handled one line up. Two verifiers confirmed this empirically against ts-morph 28.0.0: for z.infer<typeof Foo> and type T = typeof Foo the parent of Foo is TypeQuery (isTypeQuery → true, TypeOfExpression → false); for const kind = typeof Foo the parent is TypeOfExpression.

What it actually matches

Line 213 only fires for runtime typeof <schema>, e.g.:

import { ToolSchema } from '@modelcontextprotocol/server';
const kind = typeof ToolSchema;   // evaluates to "object" at runtime

When it fires, handleReference emits the diagnostic at line 73-78: "Replace z.infer<typeof ToolSchema> with the Tool type (already exported from the same v2 package)." — which is misleading: there's no z.infer, no type inference, and the user's intent (runtime typeof, always evaluates to "object") has nothing to do with type-position usage. The function name isTypeofInTypePosition also lies for this branch — TypeOfExpression is by definition not in type position.

Why the existing test doesn't exercise line 213

The test 'emits diagnostic for typeof in type position' (specSchemaAccess.test.ts:104-113) uses:

type Result = typeof CallToolResultSchema;

That's a TypeQuery — matched by line 211, not line 213. So the test passes regardless of whether line 213 exists, and provides no coverage for the TypeOfExpression branch.

Step-by-step proof

Input:

import { ToolSchema } from '@modelcontextprotocol/server';
const kind = typeof ToolSchema;

1. collectSpecSchemaImports → { ToolSchema → ToolSchema }; typeName = 'Tool'.
2. findNonImportReferences returns the ToolSchema identifier inside typeof ToolSchema. parent is a TypeOfExpression node (the runtime unary operator).
3. handleReference → isTypeofInTypePosition(ref): line 211 Node.isTypeQuery(parent) → false (it's TypeOfExpression, not TypeQuery); line 213 parent.getKind() === SyntaxKind.TypeOfExpression → true. Returns true.
4. handleReference line 72-79 pushes warning(..., "Replace z.inferwith theTool type ...") and returns false.
5. The body reference is left unchanged, so removeUnusedImport at line 30 sees referenceCount === 1 and the ToolSchema import survives → eventually TS2305 (since v2 doesn't export individual *Schema names), but with a diagnostic that points the user at z.infer instead of the actual problem.

Impact

Diagnostic-quality / dead-code only — nit severity. Runtime typeof <ZodSchemaConstant> is essentially never written in real code (it always evaluates to "object", so it's a useless expression). The source is left unchanged (return false → safe, no corruption), and the only harm when triggered is a confusing diagnostic message. But the comment on line 212 is demonstrably wrong about TypeScript's AST, the function name lies for this branch, and the check is at-best-redundant for its stated purpose. This is the same incorrect-comment / dead-code cleanup bar already applied throughout this PR's review (resolved comments 3133089882, 3143732196).

Fix

Delete lines 212-213 — Node.isTypeQuery(parent) on line 211 already covers z.infer<typeof X>, type T = typeof X, and every other type-position typeof:

function isTypeofInTypePosition(ref: import('ts-morph').Node): boolean {
    const parent = ref.getParent();
    if (!parent) return false;
    return Node.isTypeQuery(parent);
}

(If you actually want to handle runtime typeof XSchema — which seems unnecessary given how contrived it is — it should fall through to the value-position branch at line 168 and become typeof specTypeSchemas.Tool, not get the z.infer diagnostic.)

What the bug is

handleReference() now guards ExportSpecifier (line 134), ShorthandPropertyAssignment (line 145), PropertyAssignment name-node (line 159), and BindingElement property-name (line 163) — the latter two added in the most-recent commit per comment 3193275781. But the PropertyAccessExpression check at line 122 only covers the case where ref is the object of the access (parent.getExpression() === ref, i.e. ToolSchema.something). There is no corresponding guard for when ref is the name node (parent.getNameNode() === ref, i.e. obj.ToolSchema). That case falls through every pattern check and lands on the value-position rewrite at line 169.

Code path that triggers it

findNonImportReferences() (lines 51-60) collects every identifier matching localName whose parent is not an ImportSpecifier. For obj.ToolSchema, the ToolSchema identifier's parent is a PropertyAccessExpression — not filtered — so it's pushed into refs and reaches handleReference().

Why existing code doesn't prevent it

Walking the guard chain for a ref whose parent is a PropertyAccessExpression with parent.getNameNode() === ref:

• isTypeofInTypePosition — parent is not TypeQuery/TypeOfExpression → false.
• isSafeParseSuccessPattern / isSafeParsePattern / isParsePattern — all check parent.getName() === 'safeParse'/'parse' (which is 'ToolSchema' here, not 'safeParse') and parent.getExpression() === ref (expression is obj, not ref) → false.
• Line 122 — Node.isPropertyAccessExpression(parent) ✓ but parent.getExpression() === ref is false (expression is the obj identifier) → guard skipped.
• Lines 134/145/159/163 — parent is not ExportSpecifier/ShorthandPropertyAssignment/PropertyAssignment/BindingElement → all skipped.
• Line 169 — ref.replaceWithText('specTypeSchemas.Tool').

This is internally inconsistent: renameAllReferences (astUtils.ts:17) has exactly this guard — Node.isPropertyAccessExpression(parent) && parent.getNameNode() === node → return — and the test 'does not rename property access names that match renamed symbols' (symbolRenames.test.ts) locks it in for that helper. specSchemaAccess is the one transform that re-implements its own parent-kind guard list and missed this case.

Step-by-step proof

Input:

import { ToolSchema } from '@modelcontextprotocol/server';
const x = registry.ToolSchema;

1. collectSpecSchemaImports finds ToolSchema (in SPEC_SCHEMA_NAMES) → schemaImports = { ToolSchema → ToolSchema }, typeName = 'Tool'.
2. findNonImportReferences(sf, 'ToolSchema'): visits the ToolSchema identifier inside registry.ToolSchema. Parent is PropertyAccessExpression, not ImportSpecifier → pushed.
3. handleReference: every pattern check above is false; falls through to line 169.
4. ref.replaceWithText('specTypeSchemas.Tool') → source becomes const x = registry.specTypeSchemas.Tool;. This is valid TypeScript syntax (chained property access), so ts-morph does not throw — unlike the PropertyAssignment/BindingElement cases that motivated comment 3193275781, there is no runner rollback here.
5. ensureImport(sf, 'specTypeSchemas') adds specTypeSchemas to the import.
6. A misleading 'Replaced ToolSchema with specTypeSchemas.Tool…' warning is pushed — the user is told a schema reference was migrated when in fact an unrelated property access on an arbitrary object was corrupted.
7. removeUnusedImport(sf, 'ToolSchema', true) then removes the original ToolSchema import specifier (no body references remain).

Output:

import { specTypeSchemas } from '@modelcontextprotocol/server';
const x = registry.specTypeSchemas.Tool;

This may still typecheck (if registry is loosely typed) — silent semantic corruption, the worst codemod failure mode.

Impact

Nit severity. The trigger requires importing a spec schema from an MCP package and having an unrelated obj.<SchemaName> property access in the same file — contrived, in the same rarity class as the PropertyAssignment-name/BindingElement-propertyName cases just guarded at lines 159/163. But unlike those (which threw and triggered rollback), this one produces syntactically-valid output, so it's a silent corruption rather than a loud failure. It's a one-line internal-consistency fix in code that has been iteratively hardened across this PR for exactly this parent-kind-guard class (resolved comments 3189940697, 3193275781).

Fix

Add the missing guard alongside lines 159/163, mirroring astUtils.ts:17:

if (parent && Node.isPropertyAccessExpression(parent) && parent.getNameNode() === ref) {
    return false;
}

(Returning false rather than emitting a diagnostic, since a property name on an arbitrary object is not a reference to the imported schema at all — same rationale as the PropertyAssignment-name guard at line 159.) Or, more durably, factor the key-position skip list out of renameAllReferences into a shared isKeyPositionIdentifier(node) helper and reuse it both here and in findNonImportReferences.